Normally, on-board diagnostics (OBD) is a system that lights a malfunction indication lamp (MIL) on a dashboard in case of any trouble of a vehicle such that a driver can rapidly identify and remedy malfunctions of the vehicle.
There are OBD-I and OBD-II as examples of such OBD. The OBD-I checks malfunctions due to disconnection or short-circuit of many kinds of input/output sensors connected to an engine control module (ECM), and the OBD-II further checks the rationality and performance of the sensors and any abnormal operation of a vehicle system.
Typically, the OBD is equipped in a dashboard of a vehicle. The OBD provides a self-diagnosis function of a vehicle and is thus useful to a repairman or a vehicle insurance company. Also, based on a feedback from the OBD, a driver can know his or her driving habit and improve safety in driving.
The OBD may obtain status information about a vehicle from the ECM of the vehicle. For example, the ECM may monitor vehicle information, such as fuel efficiency, revolutions per minute (RPM), a vehicle velocity, or the like, through several in-vehicle sensors and then provides such vehicle information to the OBD.
The OBD may have a wireless communication module and thus operate as a wireless device.
For example, the wireless device (e.g., OBD) may receive a control command of an external device (e.g., a driver's smart phone) and then deliver the received command to a transportation device (e.g., a vehicle). For this, a communication connection between the wireless device and the external device is required.
Each of the above-mentioned devices may provide a user interface (UI) through which a user can carry out a communication connection. For example, if the respective devices comply with Bluetooth (BT) communication protocol, a device that receives a request for a communication connection may change a mode to a discoverable mode in response to a user input through the UI. Meanwhile, a device that sends the communication connection request may scan neighboring external devices and then provide a scan list that contains identification information of specific external devices which are in a discoverable mode. Additionally, in response to a user input for selecting one device in the scan list, this device may perform pairing with the selected device. In this case, for the communication connection between devices complying with the BT communication protocol, a process of providing the UI to a user may be required.
If the device that receives the communication connection request fails to provide any UI associated with a communication connection, the request-sending device may receive a user input for unique information (e.g., a PIN code, etc.) of the request-receiving device. In this case, since such device unique information is often written on a packaging box of the device, this may cause a security vulnerability issue. Additionally, since the device that requests a communication connection does not know when the request-receiving device changes a mode to the discoverable mode, undesirable battery consumption may be caused for maintaining the on-state of the discoverable mode.
Therefore, a wireless device (e.g., OBD) that tries a communication connection with an external device may be required to provide a suitable UI for receiving a user input for the communication connection. However, if such a wireless device is equipped in a transportation device, this wireless device may be located under a dashboard beyond a user's reach. In addition, this wireless device consuming a battery of the transportation device may invite a battery discharge of the transportation device. Also, since a third-party's control for the transportation device directly influences a user's safety, it is required to enhance the security between a wireless device and an external device.